(19) 


Europaisches rafentamt 
European Patent Office 
Office europeen des brevets 


(12) 


(id EP 0 838 662 A2 

♦ 

EUROPEAN PATENT APPLICATION 


(43) Date of publication: 

29.04.1998 Bulletin 1998/18 

(21) Application number: 97308378.5 

(22) Date of filing: 22.10.1997 


(51) IntCI A G01C 21/20 


(84) Designated Contracting States: 

(72) Inventor: Nomura, Takashi, 

AT BE CH DE DK ES R FR GB GR IE IT LI LU MC 

Xanavi Informatics Corporation 

NL PT SE 

Zama-shi, Kanagawa, 228 (JP) 

Designated Extension States: 


AL LT LV RO SI 

(74) Representative: Read, Matthew Charles et al 


Venner Shipley & Co. 

(30) Priority: 22.10.1996 JP 279686/96 

20 Little Britain 

London EC1 A 7DH (GB) 

(71) Applicant: Xanavi Informatics Corporation 


Zama-shi, Kanagawa 228 (JP) 



(54) Navigation system 

(57) A navigation navigation system according to 
the present invention comprises: a database apparatus 
provided with map display data constituted of data rep- 
resenting road positions and physical forms provided in 
separate sets to correspond to different scales and route 
search data constituted of data representing connection 
states of one road connecting with another road provid- 
ed in separate sets to correspond to different scales: 
and a control apparatus that, when displaying recom- 


mended route data obtained by performing a search us- 
ing the route search data at a specific first scale super- , 
imposed upon a roadmap that is displayed on a monitor- 
based upon map display data at a second scale that is 
larger than the first scale, reads out physical form data 
of the recommended route data obtained by performing 
the search using the route search data at the first scale 
based upon the map display data at the second scale 
and displays the physical form data superimposed upon 
the roadmap on the monitor. 


FIG. 5 
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Description 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

The present invention relates to a navigation sys- 
tem that is capable of searching a recommended route 
based upon a plurality of sets of map data at different 
scales and drawing the recommended route superim- 
posed upon display maps at different scale. 

2. Description of the Related Art 

Vehicular navigation systems in the known art are 
provided with a function for displaying a roadmap of the 
area where the vehicle is currently located, a function 
for accurately detecting the vehicle position through 
map matching, a function for calculating a recommend- 
ed route from a point of departure to a destination and 
the like. In these vehicular navigation systems in the pri- 
or art, roadmap display data, data for map matching and 
data for route search are separately stored in a CD ROM 
in order to maintain compatibility with existing software 
programs and also to improve the processing speed. 

The roadmap display data include widest range 
map data for displaying large areas at the smallest 
scale, most detailed map data for displaying small areas 
in detail at the largest scale and a plurality of sets of map 
data at different scales between that of the widest range 
map data and that of the most detailed map data. For 
instance, the widest range map data may be referred to 
as level 4 data, the most detailed map data may be re- 
ferred to as level 1 data and the sets of data at scales 
between those of the level 4 data and the level 1 data 
may be referred to as level 3 data and level 2 data. In 
that case, the route search data include two sets of data 
that correspond to the level 4 and level 2 roadmap data, 
and the vicinity of the point of departure and the vicinity 
of the destination are searched using the level 2 data 
and the other area is searched using the level 4 data for 
route search to reduce the length of time required for 
the route search. 

In this specification, a level with a large level 
number is referred to as a high order level, whereas a 
level with a small level number is referred to as a low 
order level. 

FIG. 21 illustrates a roadmap depiction of roadmap 
display data which are stored in memory as level 4 data 
and level 3 data. The level 4 roadmap display data and 
the level 3 roadmap display data are separately stored 
in CD ROM media. FIG. 21 A shows a roadmap corre- 
sponding to one of the meshes in the level 4 data, i.e., 
a mesh M4, in which a road D1 and two roads D2 and 
D3 that connect at intersections C1 and C2 at the two 
ends of the road D1 are present. One of the small areas 
achieved by dividing one of the meshes of the level 4 
data, i.e., the mesh M4 equally into sixteen portions, i 
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e., the hatched small area m3, constitutes a mesh of the 
level 3 data, i.e., a mesh M3 and, as shown in FIG. 21 B, 
only a portion of the road D1, i.e., a road D4 is present 
.in the mesh M3. 

s There is a problem in the system in the prior art de- 

scribed above in that when the recommended route is 
displayed superimposed upon a roadmap at level 2 or 
level 1 displayed on the monitor based upon the recom- 
mended route data which constitute the results of a 

w route search performed at level 4, a great length of time 
is required for data conversion processing. 

Also, if the detail button is operated while the road- 
map corresponding to the mesh M4 in the level 4 data 
is displayed on the monitor, the roadmap corresponding 

'5 to the mesh M3 in the level 3 data will be displayed on 
the monitor. However, since there are no identification 
data to indicate that the road D1 and the road D4 are 
the same road, it is difficult to make a given road corre- 
spond through the different levels. In addition, a similar 

20 problem exists in regard to the route search data, and it 
is difficult to make the data searched at level 2 corre- 
spond to the data searched at level 4 in recommended 
route data that are the result of a route search. Moreo- 
ver, since there are no identification data to indicate that 

25 a road in the roadmap display data and a road in the 
route search data are the same, it is difficult to achieve 
correspondence of a given road when the recommend- 
ed route data are superimposed upon the roadmap dis- 
play data. 

30 

SUMMARY OF THE INVENTION 

An object of the present invention is to provide a 
navigation system with which the processing time for su- 

05 perimposing a recommended route upon a display map 
at a lower order level by using recommended route data 
at a higher order level is reduced. 

In order to attain this object, a navigation system 
according to the present invention comprises: a data- 

•to base apparatus provided with map display data consti- 
tuted of data representing road positions and physical 
forms provided in separate sets to correspond to differ- 
ent scales and route search data constituted of data rep- 
resenting connection states of one road connecting with 

-*5 another road provided in separate sets to correspond to 
different scales: and a control apparatus that, when dis- 
playing recommended route data obtained by perform- 
ing a search using the route search data at a specific 
first scale superimposed upon a roadmap that is dis- 

so played on a monitor based upon map display data at a 
second scale that is larger than the first scale, reads out 
physical form data of the recommended route data ob- 
tained by performing the search using the route search 
data at the first scale based upon the map display data 

55 at the second scale and displays the physical form data 
superimposed upon the roadmap on the monitor. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a block diagram of an embodiment of 
a navigation system for vehicles according to the 
present invention. 

FiG. 2 shows an example of two roads intersecting 
within a mesh range. 

FIG. 3 shows a diagram illustrating link string data. 

FIG. 4 shows the structure of roadmap display data. 

FIG. 5 shows an example of a roadmap with a plu- 
rality of nodes and a plurality of interpolation points. 

FIG. 6 shows a diagram illustrating the link string 
data corresponding to the road indicated with the bold 
line in FIG. 5. 

FIG. 7 shows a diagram illustrating offset informa- 
tion that is added into link string data for reading out im- 
mediately preceding data. 

FIG. 8 shows a method for reading out the link string 
data from the rear end. 

F!Gs. 9A through 9D show different data lengths of 
node information and interpolation point information. 

FIGs. 10A and 10B show an example of attribute 1 
+ X coordinate data. 

FIGs. 11 A and IIB show an example of attribute 2 + 
Y coordinate data. 

FIG. 12 shows a diagram illustrating link numbers 
in route search data. 

FIG. 13 shows the structure of route search data. 

FIG. 14 shows an overview of the structure in the 
recommended route data. 

FIGs. 15A and 15B show a detailed diagram illus- 
trating the data structure of the node information and the 
link information in the recommended route data. 

FIG. 16 shows a flowchart outlining the main 
processing performed by the control circuit. 

FIG. 17 shows the flowchart continuing from FIG. 

16. 

FIG. 18 shows a detailed flowchart illustrating the 
background map drawing processing performed in step 
S8 in FIG. 17. 

FIG. 19 shows a detailed flowchart illustrating the 
recommended route drawing processing performed in 
step S9 in FIG. 17. 

FIGs. 20A through 20C show the procedure taken 
for drawing a recommended route in the image memory 
based upon the recommended route data in this embod- 
iment. 

FIGs. 21 A and 21 B show a diagram illustrating link 
strings and links at different levels. 

FIG. 22 shows an example of link data and node 
data in the prior art. 

FIG. 23 shows a diagram illustrating an example of 
the prior art in which the separate segments of a road 
are assigned to separate links across an intersection. 

FIG. 24 shows the relationship between route 
search data and route display data in the prior art. 


DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

FIG. 1 is a block diagram of an embodiment of a 

5 navigation system for vehicles that is internally provided 
with a map database apparatus according to the present 
invention. In FIG. 1 , reference number 1 indicates a cur- 
rent position detection apparatus that detects the cur- 
rent position of a vehicle, which is constituted with, for 

io instance, an azimuth sensor that detects the bearing of 
the vehicle while traveling, a vehicle speed sensor thaf 
detects the speed of the vehicle, a GPS sensor that de- 
tects a GPS signal from a GPS (Global Positioning Sys- 
tem) satellite and the like. 

15 Reference number 2 indicates a control circuit that 
controls the entire system and is constituted with a mi- 
croprocessor and peripheral circuits. Reference number 
3 indicates an input device for inputting destinations and 
the like for vehicles, reference number 4 indicates a 

20 DRAM that stores vehicle position information and the 
like detected by the current position detection apparatus 
1 , reference number 5 is an image memory that stores 
image data for display on a display device 6 and image 
data stored in the image memory 5 are read.out as nec- 

25 essary to be displayed on the display device 6. Refer- 
ence number 7 indicates an SRAM that stores node in- 
formation, link information and the like on the recom- 
mended route calculated by the control circuit 2. 

Reference number 8 indicates a map database ap- 

30 paratus that stores various types of data for performing 
roadmap display, route search, map matching and the 
like, which is constituted with, for instance, a CD ROM 
device, a magnetic recording device and the like. In the 
map database apparatus 8, map display data that con- 

35 -stitute information related to road physical forms, road 
classifications and the like, and route search data that 
constitute branching point information, intersection in- 
formation and the like that are not directly related to road 
physical forms, are stored. The map display data are 

40 mainly used when displaying a roadmap on the display 
device 6 and the route search data are mainly used 
when calculating a recommended route. 

Next, the data structures of the map display data 
and the route search data stored in the map database 

45 apparatus 8 are described. 

[1] Map display data 


so 


( 1 ) Overview of link string data 


Data management of the map display data in this 
embodiment is performed for each mesh range repre- 
senting one of the partitioned areas achieved by dividing 
a roadmap into specific ranges, and individual roads 
55 present in a mesh range constitute separate link strings. 
For instance, as shown in FIG. 2, when two roads D1 
and D2 intersect in one mesh range, the two roads con- 
stitute separate link strings 1 and 2, with the link string 
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1 comprising links 11 and 12 and the link string 2 com- 
prising links 21 - 23. In this example, the links in the link 
string 1 and the links in the link string 2 represent roads 
of the same type. A link is the minimum unit that can 
represent a road and, in FIG. 2. the segment between 5 
the intersections constitutes one link unit, with inherent 
numbers assigned to the individual links (hereafter re- 
ferred to as link numbers) for identification. The inter- 
sections in FIG. 2, i.e., the connection points of the in- 
dividual links are expressed as nodes NO N4. Nodes al- 10 
so constitute the start points and the end points of the 
individual links and, as detailed later, interpolation 
; points that further divide the segments between nodes 
may sometimes be provided as well. 

Also, in this embodiment, when there is a distinct '5 
structure such as a bridge, a tunnel or the like, on a road, 
the portions of the road preceding and following the 
structure constitute separate link strings. For instance, 
when there is a bridge and a tunnel on National Highway 
246, as shown in FIG. 3, the portions preceding the 20 
bridge and the tunnel, the blocks corresponding to the 
bridge and the tunnel and the portions following the 
bridge and the tunnel all constitute separate link strings. 
In FIG. 3, these strings are designated as link strings 
101 - 1 05. By making the portions preceding and follow- 25 
ing a distinctive structure on a road separate link strings, 
search of bridges, tunnels and the like on a roadmap is 
facilitated. 

The map display data comprise a plurality of sets of 
data at different scales. In the explanation of this em- 30 
bodiment the data at each scale are referred to as level 
n (n may be 1 4, for instance) data. Level 1 corresponds 
to the most detailed roadmap and as the level goes up, 
a roadmap over a wider range is presented at a smaller 
scale. Furthermore, as detailed later, in this embodi- 35 
ment identical links at different levels are managed with 
identical (inherent) link number to facilitate making data 
correspond among different levels. The link number will 
be explained later. 

40 

(2) Data structure of link string data 

To give an explanation of the roads in FIG. 2, the 
map display data are structured by providing sets of link 
string data, each including various types of information -*s 
related to the link string 1 or 2-n, for individual link 
strings, as shown in FIG. 4, and the data corresponding 
to each link string include link string information and 
node link information, with the link string information 
comprising the following types of data, as shown in FIG. so 
4. 

1 link string size 

2 number of element points v 

3 link attribute 55 

4 road name offset 

5 road number 


In addition, the node link information comprises the 
following types of data, as shown in FIG. 4. 

1 attribute 1 + X coordinate 

2 attribute 2 + Y coordinate 

3 identical node offset 

4 guide offset 

5 link number 

6 altitude information 

(3) Link string information 

In FIG. 4, the link string size represents the storage 
size of the link string data, by referring to this storage 
size, prompt access to the next link string data is 
achieved. The number of element points data indicate 
the total number of node points and interpolation points, 
the link attribute data indicate the type of road, such as 
a national highway, a prefectural road, an expressway 
or the like and the road number is the actual designation 
number assigned to a national highway or prefectural 
road. The explanation of the road name offset is omitted 
since it is not relevant to this embodiment. The interpo- 
lation points are to be explained later. 

(4) Node link information 

FIG. 5 shows the link strings 1 and 2 in FIG. 2 in 
more detail. For instance, the node link information of 
the link string 2 indicated with the bold line in FIG. 5 is 
as shown in FIG. 6. As shown in the figure, the data on 
the link string 2 include node information related to 
nodes N1. N02 and N3 (filled circles in FIG. 5) on the 
link string and interpolation point information related to 
the interpolation points (outline circles in FIG. 5). The 
node information includes positional X and Y coordi- 
nates of the node, the attribute and the link numbers of 
links connected to the node, whereas the interpolation 
point information includes the positional X and Y coor- 
dinates of the interpolation point. These positional coor- 
dinates are used as physical form data for recommend- 
ed route display or physical form data for map matching, 
to be detailed later. The link string 2 indicated with the 
bold line in FIG. 5 includes a link assigned with a link 
number 21 located between the nodes N1 and N02, a 
link assigned with a link number 22 located between the 
nodes N02 and N3 and a link assigned with a link 
number 23 connected to the node N3. As is obvious from 
FIG. 6, the node information on the node N02 is shared 
by the link with link number 21 and the link with link 
number 22. The node information and the interpolation 
point information are positioned in the data structure in 
the order in which the links are connected. Thus, by se- 
quentially reading out the link string data starting with 
the front end address, the road physical form, the road 
type and the like of the overall link string can be detect- 
ed. 

As has been explained, since, in this embodiment, 
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data are managed in units of link strings within one mesh 
range and nodes between adjacent links are shared by 
the adjacent links, the entire volume of the data can be 
reduced compared to the case in which the data are 
managed in units of links, as in the example of the prior 
art shown in FIG. 22. In FIG. 22, links LO - L3 have nodes 
NOb, N1a, N1b . .. N3a at their start points and end points 
and sets of identical node information C01, C10 ... for 
indicating identical nodes are provided as connection in- 
formation for the individual nodes. 

(5) Offset indicating an identical node 

In FIG. 5, of the nodes at the intersection of the link 
string 1 and the link string 2 and the link string 3, the 
node in the link string 1 is assigned with a reference 
number N01, the node in the link string 2 is assigned 
with a reference number N02 and the node in the link 
string 3 is assigned with a reference number N03. In the 
data structure, the sets of node information correspond- 
ing to the intersecting points N01 N03 each has a data 
item referred to as an identical node offset. 

The identical node offset is explained in detail in ref- 
erence to FIG. 7. For instance, the address value indi- 
cating a storage area for the node information of the 
node N01 in the link string 1 is stored in memory as the 
identical node offset of the node N02 in the link string 2. 
Likewise, the address value indicating the storage area 
for the node information of the link string 3 is stored in 
memory as the identical node offset of the node N01 of 
the link string 1 and the address value of the address at 
which the node information of the node N02 in the link 
string 2 is stored in memory as the identical node offset 
of the node N03 in the link string 3. 

Since nodes other than those at intersection, which 
are indicated as the intersecting points N01 - N03 in FIG. 
5, do not intersect other roads, a specific value, i.e., 
FFFFh, for instance, that indicates that no other node 
exists to constitute an identical node, is stored in the 
identical node offset storage areas of the node informa- 
tion for these nodes. 

By providing the identical node offset in this manner, 
even when there are a plurality of sets of node informa- 
tion in regard to identical nodes, as in the case of an 
intersection, the corresponding relationships among the 
individual sets of node information can be easily ascer- 
tained. Also, in contrast to an apparatus in the prior art 
shown in FIG. 23, which requires 5 nodes (NOa - NOd) 
corresponding to the intersection where three roads in- 
tersect, only three nodes (N01-N03) are required in this 
embodiment, as shown in FIG. 5, achieving a reduction 
in the data volume. 

(6) Attribute 1 

The attribute 1 , which is stored together with the X 
coordinate of a node is constituted of offset information 
for reading out the link string data in the reverse direc- 


tion. As explained earlier, in the link string data, 
the node information and the interpolation point infor- 
mation and the like are positioned in the order in which 
the actual connections are made. Because of this, by 
5 reading out the link string data sequentially from the 
front end address in the storage area, the road physical 
form can be accurately ascertained starting at the front 
end position. 

There are also situations in which it is necessary to 
w ascertain the road physical forms from the end by read- 
ing out the link string data from the end. In such a case, 
after reading out the node information or the interpola- 
tion point information at the rear end, the header position 
of the node information or the like that is set immediately 
is before in data arrangement must be detected. For in- 
stance, when reading out the link string data (FIG. 6) of 
the link indicated with the bold line in FIG. 5 from the 
end, it is necessary to first read out the node information 
on the node N3 and then to detect the header position 
20 of the interpolation point information that is set immedi- 
ately before in the data arrangement to read out the in- 
terpolation point information from this header position, 
as indicated with the arrows in FIG. 8. However, as ex- 
plained below, the data volume of the node information 
25 and the interpolation point information varies among 
various nodes and interpolation points, and the header 
positions of node information and interpolation point in- 
formation cannot be determined uniformly 

FIGS. 9A - 9D shows varying data volumes of node 
30 information and interpolation point information, with 
FIG. 9A representing a case in which node information 
or the like is constituted with two words, i.e., the X and 
Y positional coordinates, FIG. 9B representing a case 
in which node information or the like is constituted with 
35 three words by adding identical node offset to the two 
words in FIG. 9A, FIG. 9C representing a. case in which 
node information or the like is constituted of four words 
by adding guide offset information to the three words in 
FIG. 9B and FIG. 9D representing a case in which node 
-to information or the like is constituted of five words by add- 
ing a link no. to the four words in FIG. 9C. 

As. shown in FIGS. 9A - 9D, since the data volume 
of node information or interpolation point information 
varies for each case, the information that indicates the 
header positions of the node information and the inter- 
polation point information is added to the link string data 
in advance as attribute 1 data in this embodiment. In this 
embodiment, they are added together with the X posi- 
tional coordinates of the individual nodes and interpola- 
tes tion points. 

For instance, FIG. 10A shows an example in which 
the X positional coordinates are stored in the lower order 
1 1 bits and information that indicates the header posi- 
tions of various sets of node information and the like is 
55 stored in the higher order 2 bits, in the 2-byte data con- 
stituting the attribute 1 + X coordinate data. The infor- 
mation that indicates the number of words that are 
present up to the header position of each set of node 
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information or the tike is stored in these higher order 2 
bits. 

Thus, since the information that indicates the head- 
er position of the immediately preceding set of node in- 
formation or the like is added to the link string data in 
this embodiment, even when the link string data are read 
out in the reverse direction, the entire node information 
or the like can be read out without omissions. 

(7) Attribute 2 

The attribute 2, which is stored together with the Y 
coordinate of a node, includes traffic regulation informa- 
tion, road width information and number of lanes infor- 
mation The data length of each set of data of the node 
link information that constitutes the link string data is 16 
bits (2 bytes = 1 word). In the lower order 11 bits of the 
data indicating the attribute 2 + Y coordinate, the Y po- 
sitional coordinates are stored and in the higher order 5 
bits, the traffic regulation information, the road width in- 
formation and the number of lanes information are 
stored, as shown in FIG 11 A. One type of the informa- 
tion from 1 - 8 in FIG. 11 B is selected through a specific 
bit combination for the higher order 5 bits. 

Since the road width information, the traffic regula- 
tion information and the number of lanes information are 
stored by using the available bits in the 2 byte data for 
storing the positional coordinates or the like of a node, 
the road width information, the traffic regulation informa- 
tion and the like can be added to the link string data with- 
out having to increase the volume of data. 

(8) Altitude information 

When displaying a roadmap in three dimensions, 
data concerning the altitude differences among a plural- 
ity of points on the roadmap are required. Accordingly, 
as shown in FIG. 4 in this embodiment, all the altitude 
information on the various links constituting a link string 
is added at the end of the link string data. It is to be noted 
that since link string data including altitude information 
and link string data without altitude information are 
present together, each set of altitude information can be 
added to a plurality of nodes and a plurality of interpo- 
lation points. 

By adding the altitude information to the link string 
data, a roadmap can be displayed in three dimensions. 
In addition, since all the altitude information is added 
together at the end of the link string data , the altitude 
information can be readout only when it is required and 
when the altitude information is not required, such as 
when displaying a regular flat map, for instance, only the 
data immediately preceding the altitude information 
need be read out. 

(9) Inherent link numbers shared among levels 

A link number is stored between sets of the attribute 


1 + X coordinate and the attribute 2 + Y coordinate of 
node for each link. In this embodiment, the link number 
assigned to a link at the highest order level is also as- 
signed as the link number of corresponding links at low- 
s er order levels. In other words, the link number assigned 
to a link at the highest order level is also assigned as 
the link number of the corresponding links at the lower 
order levels as the inherent link number. 

Link numbers are explained in further detail in ref- 

w erence to an example shown in FIG. 1 2 It is to be noted 
that, in order to facilitate understanding, the explanation 
will be given on the data at levels 6, 4, 2 and 0 among 
the seven levels, i.e., levels 6 0. When the link string 1 
at the highest order level 6 comprises one link assigned 

15 with link number 1 , the link with the link number 1 at the 
highest order level 6 comprises two links sharing the 
identical link number 1 at level 4. The identical link at 
the highest order level 6 is constituted of the two links 
assigned with the link number 1 constituting the link 

20 string 1 and a link with the link number 1 which consti- 
tutes the link string 2 at level 2, whereas the link string 
is constituted of a link with the link number 1 constituting 
the link string 1 , a link with the link number 1 constituting 
the link string 2 and two links with the link number 1 con- 

25 stituting the link string 3 at level 0. 

By using a link number identical to that used at a 
higher order level for the link number of links at lower 
order levels that correspond to links at the higher order 
levels in. this manner, the correspondence among iden- 

30 tical link strings at different levels and the correspond- 
ence of identical link strings in the map display data and 
the route search data are facilitated, thereby achieving 
a reduction in processing time. [2] Route search data 
The route search data include a plurality of sets of 

35 data corresponding to a plurality of sets of roadmap dis- 
play data fordifferent scales, and the data for each scale 
are referred to as level m (m, may be, for instance, 2, 4) 
data. In addition, as explained before in this embodi- 
ment, identical links at different levels are managed 
through identical link number to facilitate correspond- 
ence of data at different levels and the correspondence 
with the roadmap display data. 

FIG. 13 shows the data structure of route search 
data. As shown in the figure, in the route search data, 

^5 node information that indicates the connecting relation- 
ship with other nodes is stored for each connecting point 
(node) of links, which are the minimum units for express- 
ing a road physical form. Each set of node information 
is constituted with home node information and adjacent 

so node information, with the node positional coordinates 
stored in the home node information. In the adjacent 
node information, as shown in the figure, the adjacent 
node no. : the link no. from the home node to the adjacent 
node, the link cost of the link and traffic regulation infor- 
ms mation on that link are stored. Also, various sets of node 
information are stored in the order of link connections 
and the node no. of the home node can be ascertained 
by the order in which it is stored. Because of this, even 
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without storing the node nos. of the home nodes as 
home node information, the node nos. of the home 
nodes can be ascertained, achieving a reduction in 
memory requirement. 

[3] Recommended route data 

FIG. 14 shows an outline of the data structure of 
recommended route data which represent a recom- 
mended route from a point of departure to a destination 
which has been searched based upon the route search 
data. In the recommended route data, node information 
and link information on the recommended route are 
stored, while classified in units of mesh ranges, it is to 
be noted that a mesh range refers to a partitioned range 
when a roadmap is partitioned into units of specific rang- 
es. 

As shown in FIG. 14, the recommended route data 
are constituted with a mesh code, the number of nodes, 
node information, the number of link classifications, link 
information, ferry information and tunnel information. 
The number for identifying the mesh range is stored in 
the storage area for the mesh code, the number of 
nodes present within a mesh range is stored in the stor- 
age area for the number of nodes and, as shown in detail 
in FIG; 15A, the node no., the positional coordinates, 
the distance cost and the like of each node within a mesh 
range are stored in the storage area for the node infor- 
mation. In addition, the number of link classifications 
that are present inside a mesh range is stored in the 
storage area for the number of link classifications and, 
as shown in detail in FIG. 15B : the link classification, the 
number of links, the link no. and the like of each link 
within a mesh range are stored in the storage area for 
the link information. FIG.s 1 5A and 1 5B illustrate a case 
in which there are two link strings 1 and 2 within the area 
indicated by the same mesh code 

It is to be noted that, as explained above, recom- 
mended route data are prepared at different levels and, 
in this embodiment, recommended route data at level 2 
are prepared for the vicinities of the start point and the 
end point on the recommended route while recommend- 
ed route data at level 4 are prepared for the middle range 
between the start point and the end point. 

The following is an explanation of the operation per- 
formed in this embodiment in reference to the flowchart, 
and in this embodiment, the recommended route is dis- 
played on the display device 6 in the following manner. 
The recommended route is searched by using the route 
search data at level 4 and level 2 to create recommend- 
ed route data at level 4 and level 2, and then, the rec- 
ommended route data at level 4 is converted into rec- 
ommended route data at level 2, and then based upon 
the recommended route data at level 2 and the roadmap 
display data at level 2 and level 1 , the recommended 
route is drawn and superimposed upon the roadmap at 
level 2 or level 1 , which is displayed on the display de- 
vice 6, with the recommended route highlighted with a 
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red bold line, for instance. 

FIGS. 1 6 and 1 7 are a flow chart illustrating the out- 
line of the main processing performed by the control cir- 
cuit 2. In step S1 in FIG. 16, the vehicle position is de- 

s tected by the current position detection apparatus 1 . In 
step S2, the destination, which has been input via the 
input device 3, is read in. In step S3, based upon the 
map display data stored in the map database apparatus 
8, the start point and the end point of the route search 

10 are set on roads for which route search is possible. For 
instance, the start point of a vehicle may be the current 
position of the vehicle (vehicle position) and the end 
point is the destination. 

In step S4, using route search data at level 2, route 

is search in the vicinity of the start point of the route search 
is performed, and a plurality of candidates for the rec- 
ommended route in the vicinity of the start point are se- 
lected. In step S5, using route search data at level 2, 
route search in the vicinity of the end point of the route 

20 search is performed, and a plurality of candidates for the 
recommended route in the vicinity of the end point are 
selected. 

In step S6, using route search data at level 4, route 
search is performed for routes between the candidates 

25 for the recommended routes selected in step S4 and 
step S5, and a recommended route from the start point 
to the end point is calculated. 

Route search data at different levels are used for 
the vicinities of the start point and the end point, and the 

30 middle range between the start point and the end point 
in this manner because if route search is performed us- 
ing route search data at level 2 for the entire route, the 
data quantity will be very large and, as a result, the cal- 
culation time required in route search will increase. In 

35 step S7, the information related to the recommended 
route calculated in step S6 is stored in the SRAM 7 as 
recommended route data. 

When the processing performed in step S7 in FIG. 
16 is completed, the operation proceeds to step S8 

40 shown in FIG. 1 7, in which the background map drawing 
processing, the details of which are shown in FIG. 18, 
is performed to draw (store) data related to the roadmap 
in the vicinity of the recommended route in the image 
memory 5 for display on the display device 6. First, in 

45 step Sll in FIG. 18, map display data corresponding to 
the vicinity of the current vehicle position are read from 
the map database apparatus 8 Next, in step S1 2, a por- 
tion of the map display data thus read, is drawn (stored) 
in the image memory 5. 

50 When the processing performed in step S1 2 in FIG. 

18 is completed, the operation proceeds to step S9, 
shown in FIG. 17, in which the data required to display 
the recommended route calculated in step S3 are also 
drawn over (stored) in the image memory 5. The recom- 

55 mended route drawing processing performed in step S9 
is described in more detail later. In step S10, the data 
stored in the image memory 5 are read out and the rec- 
ommended route and the roadmap in the vicinity are dis- 
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played on the display device 6. 

FIG. 19 is a detailed flowchart illustrating the rec- 
ommended route drawing processing performed in step 
S9 in FIG. 17. In step S51 in FIG. 19, the display range 
for the recommended route is set in correspondence to 
the roadmap range displayed on the display device 6. 
In step S52, a decision is made as to whether or not the 
display range for the recommended route is included 
within the range over which the route search has been 
performed using the route search data at level 4. If a 
negative decision is made, the operation proceeds to 
step S54, whereas if an affirmative decision is made in 
step S52 in FIG. 1 9, the operation proceeds to step S53 
to convert the recommended route data at level 4 stored 
in the SRAM 7 to recommended route data at level 2. 
This conversion processing is to be detailed later. 

Step S54 follows step S52 or step S53 in FIG. 19, 
and a decision is made as to whether the display scale 
of the roadmap is set at (1/10,000 or 1 /20.000) or 
(1/40,000 or .1 /80,000). If the setting is at (1/10,000 or 
1 /20,000), the operation proceeds to step S55, in which 
the recommended route is drawn over (superimposed) 
in the image memory 5, based upon the recommended 
route data at level 2 and, the road type and link numbers 
of the map display data at level 1 . 

If, on the other hand, a decision is made in step S54 
that the scale is set at (1/40,000 or 1 /80,000), the op- 
eration proceeds to step S56, in which the recommend- 
ed route is drawn over in the image memory 5 based 
upon the recommended route data at level 2, and the 
road type and link numbers of the map display data at 
level 2. 

As shown in FIGs. 13 and 14, the route search data 
and the recommended route data in this embodiment 
hold only the connection information on link connections 
and do not hold information in regard to road physical 
form. Consequently, in order to draw a recommended 
route superimposed upon the roadmap on the monitor, 
it is necessary to extract the physical form data from the 
roadmap data based upon the recommended route da- 
ta. 

FIG. 20 illustrates the procedure that is followed in order 
to display the recommended route on the monitor based 
upon the recommended route data. 

FIG. 20 A shows recommended route data at level 
4 in which the link 1 constituting the link string 1 is 
present between the front end node NO and the rear end 
node N1. FIG. 20B illustrates the recommended route 
data at level 2 and recommended route display data at 
level 2 for drawing the physical form data which are ex- 
tracted from the roadmap display data at level 2 based 
upon the recommended route data at level 2, superim- 
posed in the image memory 5. In FIG. 20B the link string 
1 of the recommended route data at level 2 comprises 
the link 1 located between the nodes NO and Na and the 
link 1 located between the nodes Na and N1 . FIG. 20C 
illustrates the recommended route display data at level 
1 for drawing the physical form data which are extracted 


from the roadmap display data at level 1 based upon the 
recommended route data at level 2, superimposed in the 
image memory 5. 

When the operation proceeds from step S54 to step 

s S56 in FIG. 19, i.e., when drawing the recommended 
route on the roadmap at level 2 based upon the recom- 
mended route data at level 2, the coordinate values of 
the node NO, the interpolation point Hb, the node Na, 
the interpolation point He and the node N1 constituting 

io the link string 1 , as shown in FIG. 20B, are read out by 
referencing the roadmap display data at level 2, with 
common link number 1 , the start node NO and the end 
node N1 of the link string 1 used as pointers. It is desir- 
able to search the map display data within identical 

is mesh code as the mesh code of the recommended route 
data in order to reduce processing time. Then, the link 
string comprising two links with the link number 1 in the 
recommended route data is drawn on the road map at 
level 2 which is drawn in the image memory 5. 

20 When the operation proceeds from step S54 to step 
S56 in FIG. 19, i.e., when drawing the recommended 
route on the roadmap at level 1 based upon the recom- 
mended route data at level 2, the coordinate values of 
the node NO, the interpolation point Hd, the interpolation 

25 point He, the node Nb, the interpolation point Hf and the 
node Nc constituting the link string 1 and the coordinate 
values of the node Nc, the interpolation point Hg, the 
interpolation point Hh, the interpolation point Hi and the 
node N1 constituting the link string 2, as shown in FIG. 

30 20C, are read out by referencing the roadmap display 
data at level 1 , with common link number 1 of the two 
links, the start node NO and the end node N1 of the link 
string 1 used as pointers. As explained before, it is de- 
sirable that mesh code at level 1 is obtained based upon 

35 mesh code of the recommended route data at level 2, 
then the map display data is searched within identical 
mesh code as the mesh code of the recommended route 
data in order to reduce processing time. Then, the link 
string comprising two links of link 1 in the recommended 

•*o route data is drawn on the roadmap at level 1 drawn in 
the image memory 5. 

It is to be noted that the processing through which 
the recommended route data at level 4 are converted to 
recommended route data at level 2 performed in step 

-*5 S53, is implemented by referencing the route search da- 
ta at level 2 with the link number 1 assigned to one link 
in the recommended route data at level 4 and the start 
node NO and the end node N1 of the link string 1 shown 
in FIG 20A used as pointers. It is desirable to perform 

so a search within the mesh code at level 2 which is spec- 
ified by the mesh code at level 4 in order to reduce the 
processing time. 

In contrast, in a map database apparatus in the prior 
art, the route search data hold the address offset infor- 
ms mation for the route display data, as shown in FIG. 24, 
instead of the inherent link number as in the present in- 
vention, and the physical form data are added to the rec- 
ommended route data, which do not have any physical 
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form data, to create route display data which are super- 
imposed upon the roadmap at the same level in image 
memory for drawing. For instance, in the prior art, the 
route search data hold address offset information 01 for 
the map display data at the same management level and s 
address offset information 02 for the map display data 
at the lower order level in regard to a route that connects 
the home node and an adjacent node N1. Because of 
this, a problem exists in that the quantity of route search 
data is large. The address offset information 01 refers 10 
to the address in the roadmap display data at the same 
level, i.e., level 4, where the positional coordinates of 
the home node NO are stored in memory and the ad- 
dress offset information 02 - 05 indicate addresses in 
the roadmap display data at the lower order level, i.e., 15 
level 2, where the positional coordinates of the home 
node NO are stored in memory. 

Thus, since the road physical form is detected from 
the roadmap display data by using the identical link 
number, the start node and the end node of the identical 20 
link at each level in the recommended route data as 
pointers in this embodiment, it is not necessary to pro- 
vide address offset information for route display data in 
the route search data and neither is it necessary to pro- 
vide road data to be used exclusively for the route dis- 25 
play, thereby achieving a reduction in the quantity of 
route search data compared to the quantity of route 
search data in the prior art. 

In addition, since, when drawing the recommended 
route data at level 2 superimposed upon a display map 30 
at level 1, the physical form data are directly read out 
from the roadmap display data at level 1 by using the 
inherent level numbers shared among individual levels 
without creating recommended route data at level 1 , the 
processing time is reduced. It is to be noted that as ex- 35 
plained above, the processing time can be further re- 
duced by performing a data search only within a mesh 
code in the roadmap display data specified by the mesh 
code of the recommended route data. 
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display data at a second scale that is larger 
than said first scale, reads out physical form da- 
ta of said recommended route data obtained by 
performing said search using said route search 
data at said first scale based upon said map 
display data at said second scale and displays 
said physical form data superimposed upon 
said roadmap on the monitor. 

2. A navigation system according to claim 1 , wherein: 
links in said map display data and said route search 
data at said second scale that are identical to links 
in said map display data and said route search data 
at said first scale are assigned with identical link 
numbers as those assigned to said links in said map 
display data and said route search data at said first 
scale. 

3. A navigation system according to claim 2 wherein: 
said control apparatus searches said map display 
data at said second scale based upon link numbers 
of links in said recommended route data at aid first 
scale and extracts physical form data of links shar- 
ing common link numbers. 


Claims 

1. A navigation system comprising: 

45 

a database apparatus provided with map dis- 
play data constituted of data representing road 
positions and physical forms provided in sepa- 
rate sets to correspond to different scales and 
route search data constituted of data represent- so 
ing connection states of one road connecting 
with another road provided in separate sets to 
correspond to different scales; and 
a control apparatus that, when displaying rec- 
ommended route data obtained by performing 55 
a search using said route search data at a spe- 
cific first scale superimposed upon a roadmap 
that is displayed on a monitor based upon map 
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(54) Navigation system 

(57) A navigation navigation system according to 
the present invention comprises: a database apparatus 
provided with map display data constituted of data rep- 
resenting road positions and physical forms provided in 
separate sets to correspond to different scales and route 
search data constituted of data representing connection 
states of one road connecting with another road provid- 
ed in separate sets to correspond to different scales; 
and a control apparatus that, when displaying recom- 
mended route data obtained by performing a search us- 
ing the route search data at a specific first scale super- 
imposed upon a roadmap that is displayed on a monitor 
based upon map display data at a second scale that is 
larger than the first scale, reads out physical form data 
of the recommended route data obtained by performing 
the search using the route search data at the first scale 
based upon the map display data at the second scale 
and displays the physical form data superimposed upon 
the roadmap on the monitor. 
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